Method for adjusting results of a polymerase chain reaction (pcr) instrument

ABSTRACT

Methods of managing results of a real-time polymerase chain reaction (PCR) instrument and software associated with such methods are described herein. One disclosed method, among others, comprises calculating, from results of the real-time PCR instrument, a fluorescence signal of a sample during a cycle of a baseline period of the real-time PCR instrument. The method further comprises determining whether or not the fluorescence signal during the baseline period increases by at least a certain percentage compared to cycles outside the baseline period. The sample is flagged as a potentially high-titer sample when the fluorescence signal increases by at least the certain percentage.

TECHNICAL FIELD

The present disclosure generally relates to polymerase chain reaction (PCR) instruments. More particularly, the disclosure relates to methods for verifying or adjusting results of sequence detection software (SDS) used in PCR instruments.

BACKGROUND

Real-time polymerase chain reaction (PCR) systems are used for amplifying a sample, such as a DNA strand, in order to make it easier to detect or identify the sequence of the sample. Real-time PCR devices use sequence detection software (SDS) for analyzing and processing the results of PCR tests. In some cases, however, the SDS is not able to accurately detect samples, which can result in improper identification of the existence or concentration of certain sequences. For example, when a sample of plasma blood is analyzed using certain Applied Biosystems PCR systems, or other systems using related SDS, the systems at times can fail to detect a high concentration of a virus, such as, for example, parvovirus B19. Consequently, the current systems can misinterpret a plasma sample containing a high titer of these viruses that would corrupt a pool of plasma, causing a significant loss of plasma resources.

Thus, a need exists in the current state of the art to address these and other deficiencies and inadequacies of the conventional systems and methods. Improvements to the conventional systems and methods, as described herein, are able to overcome these and other shortcomings of the prior art.

SUMMARY

The present disclosure describes methods for managing the results of a real-time polymerase chain reaction (PCR) instrument. According to one embodiment among many, a method disclosed herein comprises calculating, from results of the real-time PCR instrument, a fluorescence signal of a sample during a cycle of a baseline period of the real-time PCR instrument. The method also includes determining whether or not the fluorescence signal during the baseline period increases by at least a certain percentage compared to cycles outside the baseline period. Also, the method includes flagging the sample as a potentially high-titer sample when the fluorescence signal increases by at least the certain percentage.

According to another embodiment, a method is described for testing a blood sample and comprises quantifying viral nucleic acid in the blood sample using a real-time polymerase chain reaction (rtPCR) instrument by modifying the interpretation of data so that high titer samples are not misinterpreted. A fluorescence signal is calculated from PCR results provided during a baseline period. Also, it is determined whether the fluorescence signal increases by at least a predetermined percentage during the baseline period. The method also includes flagging the blood sample as a potentially high-titer sample when the fluorescence signal increases by at least the predetermined percentage.

The present disclosure also describes computer software or firmware, computer programs, software code sequences, and the like, embodied in a computer-readable medium and executable by a processing device. According to one embodiment, a software code sequence comprises logic configured to calculate a fluorescence signal of a sample during a baseline period of test cycles of a polymerase chain reaction (PCR) instrument. The software code sequence also includes logic configured to determine whether or not the fluorescence signal during the baseline period increases by at least a certain percentage compared to cycles outside the baseline period. Also, the software code sequence includes logic configured to flag the sample as a potentially high-titer sample when the fluorescence signal increases by at least the certain percentage.

Other features, advantages, and implementations of the present disclosure, not expressly disclosed herein, will be apparent to one of ordinary skill in the art upon examination of the following detailed description and accompanying drawings. It is intended that such implied implementations of the present disclosure be included herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow chart describing a process for adjusting data results from a PCR device according to one embodiment.

FIG. 2 is a flow chart describing a process for calculating threshold cycle according to one embodiment.

DETAILED DESCRIPTION

Devices/Systems currently used to process and interpret polymerase chain reaction (PCR) data can incorrectly identify the concentration of some nucleic acids in the samples. This problem can be caused by how the results of the PCR tests are processed in sequence detection software (SDS) associated with the PCR analysis. For example, a number of PCR systems, such as many of the Applied Biosystems Real-Time PCR systems, utilize SDS that can fail to accurately detect samples of blood plasma containing high concentrations of viruses, e.g., parvovirus B19. Because of the way fluorescence is detected, it is possible that a blood plasma sample containing high virus titers could be overlooked as being clean. Particularly, it has been observed that fluorescence levels during a baseline period are elevated such that when fluorescence levels of the sample are compared to the baseline levels, there appears to be no significant increase above a threshold level to indicate a concentration of a virus. Therefore, a modification is required to overcome the software deficiencies and override the errant results to properly identify the concentration of a virus, if any, in a plasma sample.

The present disclosure describes methods of detecting high concentrations of nucleic acid that are amplified using conventional PCR instruments. Nucleic acids can be detected, for example, using a fluorogenic probe, such as a TaqMan® probe. In the presence of the target nucleic acid sequence, the probe is hydrolyzed during each PCR cycle and an increase in fluorescence is measured. The SDS can use an algorithm to separate the fluorescence into component wavelengths specific to the fluorescent dyes. Early PCR cycles, e.g., cycles 3 to 15, can be specifically set by a user to establish values from which a baseline fluorescence level is determined. The user also defines a threshold value assigned for each cycle that reflects a certain level of fluorescence greater than the calculated baseline level. The threshold cycle (C_(T)) indicates the PCR cycle number during which the fluorescence generated within a reaction exceeds the threshold and also indicates the detection of nucleic acid. However, it should be noted that samples with high concentration of nucleic acids tend to amplify during the baseline period. Thus, the SDS of some conventional PCR systems reads this fluorescence as background and incorrectly interprets these high concentration samples negative for target nucleic acid, when in actuality there may be a high concentration of the target sequence. The methods of the present disclosure compensate for these inaccurate results to provide a more accurate output, if necessary, or to verify the accuracy of the prior results.

The logic described herein overcomes at least two of the flaws in the SDS of conventional systems. First, the flawed SDS is unable to appropriately detect samples containing high-titer samples of nucleic acids, which are typically amplified during the baseline period. Because a large percentage of amplification occurs during the baseline period, an increase in fluorescence of a sample is compared against a threshold level that has been improperly raised above the elevated baseline level. As a result, the flawed SDS incorrectly identifies the sample as negative. The second flaw in the conventional SDS systems is that the data file, which contains the fluorescent data for detecting an increase, does not contain embedded identifying information. As a result of this, a data file could be incorrectly matched with a different sample. Thus, any comparisons using the data file would not be match with the correct set of results.

In one aspect of the present invention, the fluorescent data is analyzed to see if at least a certain percentage increase has occurred in the normalized fluorescence over the baseline. Results having an increase that does not exceed this certain percentage may be considered as being acceptable. As an example, the percentage may be set at about 20%, such that any sample that exhibits an increase of 20% or more is flagged as a potentially high-titer sample. Also, the C_(T) values are calculated from the results and compared to those values originally calculated by the SDS. A discrepancy between the calculations indicates a potential error in the pairing of the data file with its results or could indicate an instrumentation error.

The PCR system typically takes fluorescence readings at each PCR cycle for each test sample. A component file stores the fluorescence readings separated into the component fluorescent dyes—FAM, JOE, and ROX—at each PCR cycle, where FAM and JOE are reporter dyes and ROX is a passive reference dye. In this example, the viral target is parvovirus B19. FAM would represent the viral target and JOE would represent the internal control (IC) target.

An algorithm, according to one implementation, involves calculating a normalized reporter signal (Rn). The Rn at each cycle c is calculated as the reporter dye fluorescence divided by the passive reference dye fluorescence. For the viral target:

$\begin{matrix} {{{Rn}(V)}_{c} = \frac{{FAM}_{c}}{{ROX}_{c}}} & {{eqn}.\mspace{14mu} 1} \end{matrix}$

and for internal control (IC) target:

$\begin{matrix} {{{Rn}({IC})}_{c} = {\frac{{JOE}_{c}}{{ROX}_{c\;}}.}} & {{eqn}.\mspace{14mu} 2} \end{matrix}$

Any sample generating an increase of at least 20% in viral target Rn(V) from PCR cycle 3 to cycle 15 is flagged as a potentially high-titer sample. If this is the case, then the algorithm uses the following equations to calculate the C_(T) values. First, however, the baseline fluorescence is calculated using the linear regression of Rn over the baseline, which is defined as 3 to 15 for the viral target and 3 to 27 for the IC target. For the viral target:

the slope

$\begin{matrix} {m_{FAM} = \frac{\sum\limits_{c = 3}^{c = 15}{\left( {c - \overset{\_}{c}} \right)\left( {{{Rn}(V)}_{c} - \overset{\_}{{{Rn}(V)}_{c}}} \right)}}{\sum\limits_{c = 3}^{c = 15}\left( {c - \overset{\_}{c}} \right)^{2}}} & {{eqn}.\mspace{14mu} 3} \end{matrix}$

and the intercept

b _(FAM)= Rn(V)_(c) −(m _(FAM)× c ).  eqn. 4

For the IC Target:

the slope

$\begin{matrix} {m_{JOE} = \frac{\sum\limits_{C = 27}^{C = 27}{\left( {c - \overset{\_}{c}} \right)\left( {{{Rn}({IC})}_{c} - \overset{\_}{{{Rn}({IC})}_{c}}} \right)}}{\sum\limits_{c = 3}^{c = 27}\left( {c - \overset{\_}{c}} \right)^{2}}} & {{eqn}.\mspace{14mu} 5} \end{matrix}$

and the intercept

b _(JOE)= Rn(IC)_(c) −(m _(JOE) × c )  eqn. 6

where x represents the average of x over the range of the baseline.

Then, the delta Rn (dRn) is calculated as the difference of the Rn and baseline fluorescence at each cycle. For the viral target:

dRn(V)_(c) =Rn(V)_(c)−(m _(FAM) ×c)−b _(FAM)  eqn. 7

and for the IC target:

dRn(IC)_(c) =Rn(IC)_(c)−(m _(JOE) ×c)−b _(JOE).  eqn. 8

The algorithm then calculates the slope and intercept of dRn between each cycle, beginning at cycle 2. For the previous cycle of the viral target,

the slope

$\begin{matrix} {{m(V)}_{c} = \frac{{{dRn}(V)}_{c} - {{dRn}(V)}_{c - 1}}{c - \left( {c - 1} \right)}} & {{eqn}.\mspace{14mu} 9} \end{matrix}$

and the intercept

b(V)_(c) =dRn(V)_(c)−(m(V)_(c) ×c).  eqn. 10

For the previous cycle of the IC target, the slope

$\begin{matrix} {{m({IC})}_{c} = \frac{{{dRn}({IC})}_{c} - {{dRn}({IC})}_{c - 1}}{c - \left( {c - 1} \right)}} & {{eqn}.\mspace{14mu} 11} \end{matrix}$

and the intercept

b(IC)_(c) =dRn(IC)_(c)−(m(IC)_(c) ×c).  eqn. 12

The cycle threshold C_(T) is calculated as the fractional cycle at which the dRn crosses a threshold value. For example, the threshold value for the viral target could be 0.1 and the threshold value for the IC target could be 0.02. For the viral target, if dRn(V)_(c)>0.1 and dRn(V)_(c-1)<0.1:

then

$\begin{matrix} {{C_{T}\; (V)} = {\frac{0.1 - {b(V)}_{c}}{{m(V)}_{c}}.}} & {{eqn}.\mspace{14mu} 13} \end{matrix}$

For the IC target, if dRn(IC)_(c)>0.02 and dRn(IC)_(c-1)<0.02, then

$\begin{matrix} {{C_{T}\; ({IC})} = {\frac{0.02 - {b({IC})}_{c}}{{m({IC})}_{c}}.}} & {{eqn}.\mspace{14mu} 14} \end{matrix}$

The calculated C_(T) values are rounded to two decimal places and then compared to the values from the PCR results. The comparison is used to determine whether or not the component file is correctly paired with its results file and thus originate from the same assay run.

FIG. 1 is a flow chart illustrating an embodiment of a method for managing results of conventional SDS. The method of FIG. 1 is able to overcome the deficiencies of the faulty SDS results. The method includes receiving data files, as indicated in block 10. The data files can be received, for example, from SDS of a PCR system or from other processing and/or data storage systems associated with PCR analysis. In block 12, a fluorescent signal Rn is calculated during a baseline period, which, for example, may include cycles 3 to 15 of the PCR test. In some embodiments, the fluorescence signal Rn can be a normalized reporter signal of each cycle calculated by dividing the fluorescence of a reporter dye by the fluorescence of a passive reference dye.

In block 14, the threshold cycle (C_(T)) values are calculated from the data files. As described in more detail below, FIG. 2 includes a process for implementing this calculation of C_(T) according to one embodiment. In block 16, the C_(T) values calculated in block 14 are compared to the C_(T) values received directly from the SDS. In decision block 18, it is determined whether or not the values compared in block 16 match, thereby ensuring the correct identity of the sets of results. If the values match, then the flow is directed to block 20. In block 20, an indication is made that the C_(T) values have been corrected and the newly calculated C_(T) values are verified as being reliable. If the values do not match, then the flow is directed to block 22, at which an indication is presented to the user that an error has occurred. The error could be the result of improper pairing of the newly calculated C_(T) values and the C_(T) values calculated by the SDS. The error could also be the result of an error in the instrumentation. After indication of the error in block 26, the flowchart ends.

In decision block 24, it is determined whether or not the fluorescence during the baseline period increases by at least a certain percentage, e.g., 20%, compared to the fluorescence during cycles outside the baseline period. If not, then it is determined that the sample does not contain a high titer of nucleic acid. In this case, the process includes verifying that the original values of the results of the PCR test are substantially accurate, as indicated in block 26, since the original values would not have been compared to elevated levels. When the original values are verified in block 26, the routine comes to a finish. However, if it is determined in decision block 24 that the fluorescence increase is at least the certain percentage, then the sample can be flagged as containing a high titer of nucleic acid, as indicated in block 28.

FIG. 2 is a flow chart illustrating an embodiment of a method for calculating C_(T). The method of FIG. 2 can be used, for instance, in place of block 14 shown in FIG. 1 in which C_(T) is calculated. In this method, block 30 indicates that a fluorescence signal Rn is calculated. In some embodiments, Rn is calculated by FAM/ROX. In block 32, a baseline fluorescence is calculated using a linear regression method. In alternative embodiments, other statistical methods may be used to calculate the baseline fluorescence. In block 34, a difference signal dRn is calculated in which dRn is the difference between the fluorescence signal Rn and the baseline fluorescence at each cycle. In block 36, a calculation is made of the slope and intercept of the difference signal dRn between each cycle and the previous cycle. In block 38, the cycle threshold C_(T) is calculated as the fractional cycle at which difference signal dRn crosses a threshold. In block 40, C_(T) is rounded to two decimal places.

The operations of the methods and processes described herein could be incorporated into one or more software programs and used to process the corrections and/or adjustments described herein and to generate an output of more accurate results compared with originally calculated results from traditional SDS. Such software programs could be used to replace a section of software code in any related SDS or developed into the SDS itself. The software programs could be used in SDS existing today or that which may be developed in the future. Also, the software program can be incorporated in any PCR analysis system that utilizes a similar processing format for analyzing a sample. In some embodiments, the software program could be incorporated in a stand-alone device and connected to an output of a conventional PCR system that provides the potentially faulty results as described above.

In addition to the presently disclosed methods being used to correct the output of the SDS, the method could also provide an indication of any corrections made. In this way, the methods could be used to provide the more accurate results after processing the signals as disclosed. Software logic for correcting or adjusting the signals could be stored on a computer-readable medium. In some embodiments, the methods and operations could be implemented in hardware or software and incorporated into a data management system, such as a laboratory information management system (LIMS), and/or incorporated into a spectrometer, such as an infrared interferometer spectrometer (IRIS).

It should be understood that the steps, processes, or operations of the methods described herein may represent any module or code sequence that can be implemented in hardware, software, firmware, or a combination thereof. When implemented in software or firmware, the methods can be stored in memory and executed by a processing device. When implemented in hardware, the methods can be implemented, for example, using discrete logic circuitry, an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), etc., or any combination thereof. These modules and code sequences can include commands or instructions for executing specific logical steps, processes, or operations within physical components.

It should further be understood that one or more of the steps, processes, and/or operations described herein may be executed substantially simultaneously or in a different order than explicitly described, as would be understood by one of ordinary skill in the art. The programs or software code that include executable logical instructions, as described herein, can be embodied in any suitable computer-readable medium for execution by any suitable processing device. The computer-readable medium can include any physical medium that can store the programs or software code for a measurable length of time.

The embodiments described herein merely represent exemplary implementations and are not intended to necessarily limit the present disclosure to any specific examples. Instead, various modifications can be made to these embodiments as would be understood by one of ordinary skill in the art. Any such modifications are intended to be included within the spirit and scope of the present disclosure and protected by the following claims. 

1. A method for managing results of a real-time polymerase chain reaction (PCR) instrument, the method comprising: calculating, from results of the real-time PCR instrument, a fluorescence signal of a sample during a cycle of a baseline period of the real-time PCR instrument; determining whether or not the fluorescence signal during the baseline period increases by at least a certain percentage compared to cycles outside the baseline period; and flagging the sample as a potentially high-titer sample when the fluorescence signal increases by at least the certain percentage.
 2. The method of claim 1, wherein the certain percentage is 20%.
 3. The method of claim 1, further comprising: verifying that original fluorescence values detected by sequence detection software (SDS) associated with the PCR are substantially accurate when it is determined that the fluorescence signal during the baseline period does not increase by at least the certain percentage.
 4. The method of claim 1, further comprising: calculating the threshold cycle (C_(T)) from original fluorescence values detected by sequence detection software (SDS) associated with the PCR; and comparing the C_(T) with threshold cycle values detected by the SDS to determine if there is a match.
 5. The method of claim 4, further comprising: indicating the C_(T) calculated from the original fluorescence values as the correct values when there is a match; and indicating the occurrence of an error when there is not a match.
 6. The method of claim 4, wherein calculating C_(T) further comprises: calculating a fluorescence signal as a ratio of FAM/ROX; calculating baseline fluorescence using a linear regression method; calculating a difference signal between the fluorescence signal and the baseline fluorescence at each cycle; calculating the slope and intercept of the difference signal between each cycle and the previous cycle; and calculating the C_(T) as the fractional cycle at which the difference signal crosses a threshold.
 7. A method for testing a blood sample, the method comprising: quantifying a blood sample using a real-time polymerase chain reaction (PCR) instrument to provide PCR results; calculating a fluorescence signal from PCR results provided during a baseline period; determining whether the fluorescence signal increases by at least a predetermined percentage during the baseline period; and flagging the blood sample as a potentially high-titer sample when the fluorescence signal increases by at least the predetermined percentage.
 8. The method of claim 7, further comprising: verifying that the PCR results are substantially accurate when it is determined that the fluorescence signal during the baseline period does not increase by at least the predetermined percentage.
 9. The method of claim 7, further comprising: calculating the threshold cycle (C_(T)) from the PCR results; and comparing the C_(T) with threshold cycle values detected by sequence detection software (SDS) associated with the PCR to determine if there is a match.
 10. The method of claim 9, further comprising: indicating the C_(T) calculated from the PCR results as the correct values when there is a match; and indicating the occurrence of an error when there is not a match.
 11. The method of claim 9, wherein calculating C_(T) further comprises: calculating a fluorescence signal; calculating a baseline fluorescence using a linear regression method; calculating a difference signal between the fluorescence signal and baseline fluorescence at each cycle; calculating the slope and intercept of the difference signal between each cycle and the previous cycle; and calculating the C_(T) as the fractional cycle at which the difference signal crosses a threshold.
 12. A software code sequence embodied in a computer-readable medium and executable by a processing device, the software code sequence comprising: logic configured to calculate a fluorescence signal of a sample during a baseline period of test cycles of a polymerase chain reaction (PCR) instrument; logic configured to determine whether or not the fluorescence signal during the baseline period increases by at least a certain percentage compared to cycles outside the baseline period; and logic configured to flag the sample as a potentially high-titer sample when the fluorescence signal increases by at least the certain percentage.
 13. The software code sequence of claim 12, wherein the certain percentage is 20%.
 14. The software code sequence of claim 12, further comprising: logic configured to verify that original fluorescence values detected by sequence detection software (SDS) associated with the PCR are substantially accurate when it is determined that the fluorescence signal during the baseline period does not increase by at least the certain percentage.
 15. The software code sequence of claim 12, further comprising: logic configured to calculate the threshold cycle (C_(T)) from original fluorescence values detected by sequence detection software (SDS) associated with the PCR; and logic configured to compare the C_(T) with threshold cycle values detected by the SDS to determine if there is a match.
 16. The software code sequence of claim 15, further comprising: logic configured to indicate the C_(T) calculated from the original fluorescence values as the correct values when there is a match; and logic configured to indicate the occurrence of an error when there is not a match.
 17. The software code sequence of claim 15, wherein the logic configured to calculate C_(T) is further configured to: calculate a fluorescence signal; calculate baseline fluorescence using a linear regression method; calculate a difference signal between the fluorescence signal and baseline fluorescence at each cycle; calculate the slope and intercept of the difference signal between each cycle and the previous cycle; and calculate the C_(T) as the fractional cycle at which the difference signal crosses a threshold.
 18. The software code sequence of claim 12, wherein the software code sequence is embodied in sequence detection software.
 19. The software code sequence of claim 12, wherein the software code sequence is embodied in a stand-alone device configured to receive PCR results from sequence detection software associated with the PCR. 